General

• The teacher dashboard starts up a local jetty server.
• The jetty server is running a intrasession-proxy servlet which we would have to create.
• The url to the intrasession-proxy servlet is set in the group overlay and set to the CC server.
• When the clients start, or when they refresh they pick up this new URL. And use it instead of the one they have been using
• currently the group overlay is only requested once when the students start. This should probably be changed so it is requested each time or checked each time. That would allow the url to change when the teacher starts up the dashboard, and it would allow new students to be registered to the class while it is starting.
• the URL to the teachers server should probably be set in a special way, so if someone outside of the class is monitoring the class (like a dev at CC) or a student home sick, they can still watch the progress.

Intrasession-proxy servlet

• handles the get, put, and mkcol requests from the clients.
• it is initialized with all the data from the CC server
• as student changes come in they are stored locally, and in a background thread sent up to the CC server.
• conflicts are dealt with in an time based overriding way, but they are versioned on the CC server, and some log is kept of them so we can try to reduce them
• before the teacher dashboard is exited, all changes are sent to the CC server if possible.
• if it is actually useful the servlet can check for changes on the CC server this would handle the case of the student working at home, because their changes would be on the CC server not in the local server. This would have to be a polling based operation. It could happen each time a request for that students data is made by another computer, with some kind of time out or expiration. If the check for CC server side changes is cheap then this could block the incoming request while waiting for the changes. If it is slow just to find out if there are CC server changes then it probably shouldn't block.
• a simple implementation might not store the data after it quits
  • each GET would look for updates on the server, and use an expiration setting so when several request come in at the same time no all are sent out remotely.
  • each PUT would store it locally and put it on the server
  • this simple approach is still better because it reduces the number of requests, by combining them.

Changes to client code

• the client code needs to do the mkcol requests instead of the diy. Otherwise the local server will not have folders for classes that are just starting up.

Use of git or subversion

• in order to efficiently do the sync between the local server and the CC server, git or subversion could be used.

Subversion

• the CC server is already using subversion to store student work
• the servlet can do an svn co or svn up of the classes folder on the CC server
  • the CC server folder structure would need to be reorganized to have folders like this.
• after the co then the servlet would just server the files in this folder and after each PUT it would do an svn ci.
• if during the svn ci it found a coflict it would do a force to override the conflict, but it would log this overriden version somewhere (if svn doesn't already do that), it could be an svn prop, or a REST api on the server.
• for looking for file requests made by students it could do a svn up for each one to see if there are changes on the server. That would probably be too slow so it would probably have to run in the background.
• the folder can be saved after the program exits so it can startup again, without downloading everything.
• benefits
  • this would only pull down the latest revision from the server
  • it should do binary differencing to only get the good changes.
  • it might be slower

Git

• each class would need to be in its own git repository
• a pull could be down to get just the most recent revision of that class repository
  • however I think then a push couldn't be done later.
• if pushes work, then after each PUT by a student a push would be done of the whole repository.
• when students make GIT requests a pull request can be triggered